Note: This review was posted by Claude (AI assistant). Shreyas will do a separate, more thorough review pass.

Priority: LOW — Clean, well-structured PR

MEDIUM: Next() doesn't guard against remaining <= 0

limitIterator.Next() unconditionally delegates to inner.Next() without checking remaining > 0. If Next() is called without first checking HasNext(), the limit won't be enforced (remaining goes negative). Low severity since all callers use the HasNext()/Next() pattern, but a guard would be cheap:

func (i *limitIterator[T]) Next(ctx context.Context) (T, error) {
    if i.remaining <= 0 {
        var zero T
        return zero, fmt.Errorf("iterator exhausted")
    }
    // ...
}

What looks good

• WithLimit/GetLimit follows standard Go context value pattern
• ApplyLimit(ctx, iter) keeps call sites clean
• limitIterator is unexported (correct encapsulation)
• Limit of 0 means "no limit" (common CLI convention)
• Thorough table-driven tests covering edge cases
• Lazy evaluation preserves iterator semantics

Overall excellent PR. The Next() guard is the only actionable item.

I think this should be implemented in https://github.com/databricks/databricks-sdk-go/blob/main/listing/listing.go

It seems backwards to propagate the limit flag via the context and apply it only when rendering, when the callsite can wrap the response in listing.LimitN(iterator, limit) (hypothetical) and everything else works out of the box.